Настольная книга тимлида разработки ПО - Виктор Большаков
— Регламентируем там, где нужно.
Если взаимодействие приводит к конфликтной ситуации его необходимо регламентировать — согласовать с другим подразделением точный интерфейс взаимодействия. Кто, кому, что, как и когда передает? Обычно это не односторонний процесс, он снабжен обратной связью, которую тоже требуется регламентировать. Помните, любые регламенты несут риски того, что одна из операций не подойдет и регламент сработает во вред, а не на пользу.
— Сотрудничество, а не соперничество.
Если в компании есть похожее подразделение, вы можете вместе искать способ стать лучше. При этом помните, что обмен знаниями и опытом принесет максимальную пользу для всей компании.
— Эскалация в необходимых случаях.
В некоторых ситуациях необходимо эскалировать вопросы до руководства. Невозможно всё регламентировать и предусмотреть, так что такие ситуации будут происходить (особенно из-за наличия конфликтующих целей). Для этого необходимо донести до руководства информацию о том, что в другом подразделении приоритеты выставлены неподходящим для вас образом или стиль их работы конфликтует с вашим. В этом случае вы можете в диалоге с другим подразделением открыто заявить о необходимости эскалации вопроса для поиска более правильного решения в интересах компании.
Члены вашей команды и вы легко найдете повод сплотиться против единого врага. Если вы думаете, что в качестве врага можно выбрать другое подразделение компании, это заведомо неправильная позиция. Ведь через какое-то непродолжительное время такой подход выстроит отношения на ненависти и нежелании слушать и слышать другую сторону. Обычно такие отношения взаимны, но не долгосрочны — очень скоро это будет замечено руководством и вам будет поручено наладить отношения, выстроив плодотворный созидательный труд. Заметьте, вы можете проявить непрофессионализм и продолжать искренне ненавидеть своих коллег, но это уже ваша личная позиция, работающая против общих целей. Даже если вы 100 раз правы и в другом подразделении работают непрофессионалы, вы не можете судить о том, насколько это плохо, пока не обсудите это с руководством (может быть гораздо больше причин в пользу сложившейся ситуации, чем против нее).
Строить стены плохо, как их разрушить?
— Наладить обмен информацией между подразделениями и повысить ее прозрачность.
— Создать культуру благодарности, чтобы усилия каждого сотрудника признавались, а не воспринимались как должное.
— Обмениваться новостями, чтобы все имели доступ к информации и в коллективе формировались здоровые отношения.
— Разберите конфликт, формализуйте обмен информацией/результатами труда, выстроите процесс более формально чтобы исключить недопонимания и ошибочные ожидания.
— Найдите повод регулярно вместе общаться на рабочие и нерабочие темы. Как показывает практика, проявлять неуважение проще через почту, мессенджеры и т. д. В живом общении людям сложнее проявлять негативные эмоции и проще решать конфликты.
Управление ожиданиями от команды
Начните с вопросов:
— Зачем команда существует?
— Зачем команда нужна будет дальше?
Вы должны понимать, что лишь часть ожиданий формализована и доведена до вас — это бывает связано с различием в восприятии или неспособностью систематизировать ожидания. В любом случае полного детального описания того, что от вас ожидают вы скорее всего не получите.
Ожидания меняются со временем, и вы должны постоянно сверяться с тем, что от вас требуется.
Управление ожиданиями — это предмет двустороннего обсуждения. Если в компании или конкретном бизнес-направлении есть определенные цели, то ваша задача понять, как их можно достичь и какие для этого потребуются ресурсы и сроки. Желание делать и не нести никакой ответственности за сроки напрямую влияет на качество, что возвращает вас на шаг назад из позиции тимлида в позицию разработчика-исполнителя.
Старайтесь максимально конкретизировать цели (в идеале по S.M.A.R.T.) — не завышайте ожидания, оставляйте резервы для покрытия рисков и заранее продумывайте шаги для достижения поставленных целей. Поскольку это командная работа, она не может избежать влияния внешних факторов. Ваша задача определить их и скорректировать ожидания от команды. Правильный подход: «задача будет сделана в срок, если мы…». Также стоит учитывать дополнительные расходы при определении сроков на поддержку продуктов, плановый рефакторинг и др.
В разных компаниях по-разному выстроен процесс формализации ожиданий и их управления, он может опираться на результаты:
— Спринтов
— Дорожной карты
— Системы контрактов.
Стратегические ожидания будут размываться тактическими и операционными. Причем контроль всех уровней ожиданий будет на вашей стороне. Держите в фокусе команды стратегические ожидания при любых обстоятельствах и временных изменениях курса.
Требуйте обратную связь по достигнутым результатам. Выполненные задачи и достигнутые цели — это ценность, которую организация получила от работы команды. Команде важно получить эту обратную связь, и ваша функция ее транслировать. Если обратная связь негативная, вы должны принять удар на себя.
В том случае если цель размазана и не выражена какими-то конкретными границами, найдите ориентир обратной связи в виде метрик продукта или опросов заказчиков. Бизнес редко готов делиться финансовыми результатами или оборотами, для этого существуют более безопасные метрики в виде количества активных пользователей, объема операций или возврата посетителей (retention).
PR и DevRel
Ценность внутреннего PR вашего подразделения в рамках компании может быть выражена в: распределении премиального фонда в вашу пользу, потенциале роста, узнаваемости ваших сотрудников, понимании другими подразделениями специфики вашей работы.
Как этого можно добиться:
— Публиковать наиболее интересные задачи, которые вы решили
— Увлеченно рассказывать о ваших специалистах
— Приглашать другие подразделения на открытые внутренние доклады
— Публиковать статистику решаемых задач, метрик систем в проде
DevRel — отношения с разработчиками, чаще всего подразумевается внешний Tech PR. На такую деятельность в маленьких компаниях не находят ресурса, однако если даже не выделять отдельного специалиста, работа коллектива может быть организована таким образом, что такой Tech PR будет появляться естественным образом.
Основная цель DevRel — повысить узнаваемость бренда, что улучшит процесс найма.
Деятельность, развивающая DevRel:
— Участие в open-source проектах
— Публикация исследовательских задач, с которыми вы сталкиваетесь в работе, и их результатов
— Участие с докладами или вопросами в конференциях и митапах
— Участие в хакатонах и интервью
Деятельность PR и DevRel организации невозможна без привлечения компетентных сотрудников. Ваша инициатива и участие — ключ к успеху компании.
Владелец процесса разработки
Принципы построения процессов
При построении процессов необходимо придерживаться следующих принципов:
— Каждый процесс имеет определенную цель, вы должны сформулировать ее четко и ясно
— Превратите цель в последовательную модель входов-выходов
— Не регламентируйте то, где
